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(57) Abstract 



A Web/Internet based toll-free network management tool (200) that enables customers (100) of telecommunication network providers 
to modify the configuration of their toll-free networks via a Web/Internet-bases graphical user interface (80, 292). The tool (200) provides 
customers (100) Web/Internet access to toll-free call routing plans and associated routing plan details (225) via a secure Web/Internet-based 
connection (22), and additionally provides a customer with the ability to specify implementation of a specific call routing plan for a toll-free 
number at a predetermined time, and the ability to re-configure an existing call routing plan (222, 224). Additionally, the tool (200) enables 
a roll-back (41 6a, 416b) of a particular call-routing plan or call plan detail to a prior configuration at a user-specified time. 
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INTEGRATED PROXY INTERFACE FOR WEB BASED 
TELECOMMUNICATION TOLL-FREE NETWORK MANAGEMENT 

The present invention relates generally to 
5 information delivery systems and, particularly, to a 

novel, WWW/Internet -based, telecommunications network 
management service for customers of a 
telecommunications service provider. 

Telecommunications service entities, e.g., 

10 MCI, AT&T, Sprint, and the like, presently provide for 

the presentation and dissemination of customer account 
and network data management information to their 
customers predominantly by enabling customers (clients) 
to directly dial-up, e.g., via a modem, to the entity's 

15 application servers to access their account 

information, or, alternately, via dedicated 
communication lines, e.g., ISDN, T-l, etc., enabling 
account information requests to be initiated through 
their computer workstation running, for example, a 

20 Windows -based graphical user interface. The requests 

are processed by the entity's application server's, 
which retrieves the requested customer information from 
one or more databases, processes and formats the 
information for downloading to the client's personal 

25 computer, or more primitively, a 3270 dumb terminal or 

a low- end workstation. 

Telecommunications service providers that 
offer 800/8xx toll-free network service to their 
customers currently provide some type of user 

30 interaction to manage their 800/8xx network call 

routing plans. These plans may be pre-arranged and 
activated either by customer initiation, i.e., dial-up 
with a user access code and identification number, or, 



SUBSTITUTE SHEET (RULE 26) 



WO 99/16230 



PCT/US98/20137 



activated automatically at some prearranged time 
according to a prearranged schedule. For example, a 
customer may have a routing plan designed for "normal" 
conditions and other plans for special conditions, 

5 e.g., weekend, holiday, promotions, etc. which may be 

automatically activated. Additional enhanced toll-free 
number management features are currently available to 
customers. For instance, customers can add, change or 
delete their enhanced routing trees or routing plans in 

10 . near- real time for their toll-free numbers, for 

example, to respond to traffic conditions, emergencies 
etc. 

The assignee of the present invention, MCI, 
currently provides an MCI ServiceView ( "MSV" ) product 

15 line that provides its business customers with Windows - 

based client -server applications including an 800- 
Network Manager ("800NM") which is a PC-Windows based 
GUI to MCI's Network Control System ("NCS"). 
Particularly, NCS is used to perform enhanced routing 

20 on MCI's network for special service calls. The legacy 

order entry system for NCS is referred to as Network 
Capabilities System ( "NetCap" ) . Orders for a 
customer's routing features for that customer's 800/8xx 
traffic are entered into NetCap which processes the 

25 order (edits, validates, logs) and submits orders to a 

Service Control Manager ("SCM") which then formats and 
distributes orders to each of three redundant data 
access points ("DAPS") which implements the plan orders 
at the network switches.. Once an order is implemented 

30 on the DAPS, calls to the customer's 800/8xx number are 

processed with the features specified in the order. 
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Particularly, NetCap is a mainframe MVS 
system that implements an on-line subsystem for 
accepting orders for toll-free and VNET routing plans. 
It also has a background -processing subsystem that 
5 takes these orders, processes them, stores them in a 

database, and feeds orders to SCM. Currently, there 
are three methods for accessing NetCap: a direct 3270 
terminal connection for internal MCI users which 
provides access to 100 percent of NetCap 's functions; a 

10 PC-based 3270 terminal emulation program that utilizes 

56kbps dial-up access to a majority of NetCap 
functions; and, a PC -based Windows application entitled 
"800NM" , written in C++, for example, which enables 
customers to implement and configure routing plans for 

15 toll free and virtual networks (VNET) via the existing 

MCI Service View (MSV) infrastructure comprising a 
private network of routers and protocol converters that 
connect PC Windows applications to NetCap. 

Additionally supported by MCI is an 800 

20 Configuration Manager which is an 3270 mainframe based 

product having the following capabilities: 

1) Managing Logical Termination ("Lterm".) 
orders by providing capability to add, change, or 
delete Dialed Number Identification Service ("DNIS") 

25 and Enhanced DNIS values. These service features 

affect the termination of a Toll Free call by allowing 
customers to terminate two or more 8xx numbers to a 
single service group to receive pulsed digits and 
identify the specific 8xx number dialed. The 800 CM 

30 functions allow users to add, change, or delete DNIS 

digits for a termination already using DNIS. 

-3- 
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2) Providing Network Call Redirect ("NCR") 
functionality allowing customers to define, activate, 
and display NCR tables comprising instructions for 
calls needing termination overflow. 
5 3) Displaying of "toll-free network trigger 

points and active/inactive status. 

4) Enabling the management of supplemental 
codes, e.g., ID Codes and Accounting Codes, that are 
additional numbers entered after a Toll Free number is 

10 . dialed. 

5) Providing Call blocking service at the 
following levels: Geographic, 8xx, Enterprise, Corp 
Id, and ANI (8xx, SAC, Freephone) . 

6) Providing Enhanced Voice Services ("EVS") 
15 including automated voice response, voice processing, 

0 

and call routing functionality. The call processing 
behind EVS is Enhanced Call Routing (ECR) which is 
supported by 800 CM to control routing plans on the 
MRS/ECR platform. The current ECR environment uses 
20 'hidden' 800 numbers to build and control the routing 

after it leaves the platform. 

7) Providing Intelligent Call Routing ("ICR") 
features through MCI's NetCap order entry system which 
allows customers to control the routing of their 

25 incoming Toll Free traffic on a call by call basis. 

Using rules defined by the customer, changes in Toll 
Free traffic routing are performed in real time based 
on changes in status at customer terminations. 
Particularly, NetCap flags the Corporate ID as an ICR 

30 account; creates and maintains trigger points; and 

creates and maintains destination labels. 
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Thus, for a special service number (i.e., 
800/8xx number) , NetCap functions enable a customer to 
define up to 100 routing plans, only one of which is 
active at any time. Multiple routing plans are used by 
NetCap 1 s alternate routing feature: a customer can 
change routing plans on- the- fly with a NetCap "IMPL" 
order. A plan can specify routing rules (where to 
route a call) that are based on point of call 
origination, day of week, time of day, percent 
allocation of traffic, arid other features. Features are 
specified with a NetCap ''FEAT'' order. A customer can 
also submit a NetCap "QUIK" order to temporarily change 
the percent allocation of traffic for a number. This is 
used, for example, in the case of a disaster at a 
certain destination. NetCap may also be used to 
configure terminations; configuration includes 
specification of outpulsed digits, whether termination 
is domestic or international (determines signaling) , 
whether termination is a Dedicated Access Line or a 
shared Feature Group (determines signaling) , and 
overflow routing. 

Currently, the IMPL, FEAT, and QUIK orders 
are provided by the MSV 800NM platform. 

While the current 800NM and tollfree network 
management features in the current MSV platform are 
sufficient for those with existing access, a need 
exists to provide a newer, faster platform with new 
toll free network management capabilities for customers 
through the public Internet. 

Moreover, a need exists to integrate the 
existing tollfree network management client - server 
application in a Web -based platform which provides 

-5- 
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expedient comprehensive and more secure data access and 
reporting services to customers from any Web browser on 
any computer workstation anywhere in the world. 

The present invention is directed to a novel 
toll-free network management tool for a Web -based 
(Internet and Intranet) client- server application that 
enables customers to define their own 800/8xx toll free 
number routing plans via the Web/Internet. The toll- 
free network management tool enables customers to 
change and modify their existing 800/8xx toll free 
number routing plans, e.g., specifying routing rules 
for directing 800/8xx toll free calls along different 
routes and terminations based on pre- determined 
criteria, or, temporarily change the percent allocation 
of traffic for a particular 800/8xx toll free number 
based on certain criteria. The client server 

* 

application is a Web-based, object-oriented application 
that implements a Remote Method Invocation- like 
protocol providing customers with toll-free network 
management features including: stacking order 
capability, e.g., to temporarily change the routing of 
toll free traffic; enabling enhanced order queries; 
enabling the automatic notification of order completion 
or rejection; and providing enhanced inventory 
reporting. 

According to the principles of the invention 
there is provided a toll-free network management tool 
that enables customers of telecommunications network 
providers to modify the configuration of their toll- 
free networks via a Web/Internet -based graphical user 
interface. The tool provides customers Web/Internet 
access to toll-free call routing plans and associated 

-6- 
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routing plan details via a secure Web/Internet-based 
connection, and additionally provides a customer with 
the ability to specify implementation of a specific 
call routing plan for a toll-free number at a 
predetermined time, and the ability to re- configure an 
existing call routing plan. Additionally, -the tool 
enables a roll -back of a particular call -routing plan 
or call plan detail to a prior configuration at a user- 
specified time. 

Further features and advantages of the 

invention will become more readily apparent from a 
consideration of the following detailed description set 
forth with reference to the accompanying drawings, 
which specify and show preferred embodiments of the 
invention, wherein like elements are designated by 
identical references throughout the drawings; and in 
which: 

Figure 1 illustrates the software 
architecture component comprising a three- tiered 
structure; 

Figure 2 is a diagrammatic overview of the 
software architecture of the networkMCI Interact 
system; 

Figure 3 is an illustrative example of a 
backplane architecture schematic; 

Figure 4 illustrates an example client GUI 
presented to the client/customer as a browser web page; 

Figure 5 is a diagram depicting the physical 
networkMCI Interact system architecture; 

Figure 6 is a general block diagram depicting 
the physical architecture of the TFNM system 
components ; 

-7- 
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Figure 7 is a flow diagram depicting the web- 
based, toll free network manager of the invention; 

Figure 8 illustrates an exemplar nMCI . 
Interact systems home page; 
5 Figures 9 (a) -9(c) illustrate an exemplary 

TFNM screen providing functionality through. .option 
menus ; 

Figure 10 illustrates an example display when 
the File/Select Corp ID menu option of Figure 8 is 
10 selected; 

Figure 11 illustrates an exemplar screen 
display depicting a hierarchical tree view of an 
example toll-free number routing plan; 

Figure 12 illustrates an example IMPL dialog 
15 screen enabling the user to generate a TEMP IMPL/IMPL 

order for a desired Corp Id; 

Figure 13 illustrates an example QUIK dialog 
screen enabling the user to generate a TEMP QUIK/QUIK 
order for a desired Corp Id; 
20 Figure 14 illustrates an exemplar screen 

display showing the results of an order query; 

Figure 15 illustrates an exemplary screen 
display showing the options for changing existing 
network plan routing orders. 

25 The present invention is one component of an 

integrated suite of customer network management and 
report applications using a Web browser paradigm. 
Known as the networkMCI Interact system ("nMCI 
Interact") such an integrated suite of Web-based 

30 applications provides an invaluable tool for enabling 

customers to manage their telecommunication assets, 
quickly and securely, from anywhere in the world. 
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The nMCI Interact system architecture is 
basically organized as a set of common components 
comprising the following: 

1) an object-oriented software architecture 
5 detailing the client and server based aspect of nMCI 

Interact; 

2) a network architecture defining the 
physical network needed to satisfy the security and 
data volume requirements of the networkMCI System; 

10 3) a data architecture detailing the 

application, back-end or legacy data sources available 
for networkMCI Interact; and 

4). an infrastructure covering security, order 
entry, fulfillment, billing, self -monitoring, metrics 

15 and support. 

Each of these common component areas will be 
generally discussed hereinbelow. 

Figure 1 is a diagrammatic illustration of 
the software architecture component in which the 

20 present invention functions. A first or client tier 10 

of software services are resident on a customer work 
station 10 and provides customer access to the 
enterprise system, having one or more downloadable 
application objects directed to front end business 

25 logic, one or more backplane service objects for 

managing sessions, one or more presentation services 
objects for the presentation of customer options and 
customer requested data in a browser recognizable 
format and a customer supplied browser for presentation 

30 of customer options and data to the customer and for 

internet communications over the public Internet. 
Additionally applications are directed to front end 
services such as the presentation of data in the form 
of tables and charts, and data processing functions 
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such as sorting and summarizing in a manner such that 
multiple programs are combined in a unified application 
suite. 

A second or middle tier 12, is provided 
having secure web servers and back end services to 
provide applications that establish user sessions, 
govern user authentication and their entitlements, and 
communicate with adaptor programs to simplify the 
interchange of data across the network. 

A third or back end tier 15 having 
applications directed to legacy back end services 
including database storage and retrieval systems and 
one or more database servers for accessing system 
resources from one or more legacy hosts. 

Generally, the customer workstation includes 
client software capable of providing a platform- 
independent, browser-based, consistent user interface 
implementing objects programmed to provide a reusable 
and common GUI abstraction and problem -domain 
abstractions. More specifically, the client- tier 
software is created and distributed as a set of Java 
classes including the applet classes to provide an 
industrial strength, object-oriented environment over 
the Internet. Application- specif ic classes are 
designed to support the functionality and server 
interfaces for each application with the functionality 
delivered through the system being of two -types: 1) 
cross-product, for example, inbox and reporting 
functions, and 2) product specific, for example, toll 
free network management or Call Manager functions. The 
system is capable of delivering to customers the 
functionality appropriate to their product mix. . 

Figure 2 is a diagrammatic overview of the 
software architecture of. the networkMCI Interact system 

-10- 
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including: the -Customer Browser (a.k.a. the Client) 20; 
the Demilitarized Zone (DMZ) 17 comprising a Web 
Servers cluster 24; the MCI Intranet Dispatcher Server 
26; and the MCI Intranet Application servers 30, and 

5 the data warehouses, legacy systems, etc.. 40. 

The Customer Browser 20, is browser enabled 
and includes client applications responsible for 
presentation and front.-end services. Its functions 
include providing a user interface to various MCI 

10 services and supporting communications with MCI's 

Intranet web server cluster 24. As illustrated in 
Figure 3, the client tier software is responsible for 
presentation services to the. customer and generally 
includes a web browser 14 and additional object - 

15 oriented programs residing in the client workstation 

platform 20. The client software is generally 
organized into a component architecture with each 
component generally comprising a specific application, 
providing an area of functionality. The applications 

20 generally are integrated using a "backplane" services 

layer 12 which provides a set of services to the 
application objects which provide the front end 
business logic and manages their launch. The 
networkMCI Interact common set of objects provide a set 

25 of services to each of the applications such as: 1) 

session management; 2) application launch; 3) inter - 
application communications; 4) window navigation among 
applications; 5) log management; and 6) version 
-management. 

30 The primary common object services include: 

graphical user interface (GUI) ; communications; 
printing; user identity, authentication, and 
entitlements; data import and export; logging and 
statistics; error handling; and messaging services. 

-11- 
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Figure 3 is a diagrammatic example of a 
backplane architecture scheme illustrating the 
relationship among the common objects. In this 
example, the backplane services layer 12 is programmed 
5 as a Java applet which can be loaded and launched by 

the web browser 14. With reference to Figure 3, a 
typical user session starts with a web browser 14 
creating a backplane 12, after a successful logon. The 
backplane 12, inter alia, presents a user with an 

10 ' interface for networkMCI Interact application 

management. A typical user display provided by the 
backplane 12 may show a number of applications the user 
is entitled to run,, each application represented by 
buttons depicted in Figure 3 as buttons 58a,b,c 

15 selectable by the user. As illustrated in Figure 3, 

upon selection of an application, the backplane 12 
launches that specific application, for example, 
Service Inquiry 54a or Alarm Monitor 54b, by creating 
the application object. In processing its functions, 

20 each application in turn, may utilize common object 

services provided by the backplane 12. Figure 3 shows 
graphical user interface objects 56a, b created and used 
by a respective application 54a, b for its own . 
presentation purposes. . 

25 Figure 4 illustrates an example client GUI 

presented to the client/customer as a browser web page 
80 providing, for example, a suite 70 of network 
management reporting applications including: MCI 
Traffic Monitor 72; an alarm monitor 73; a Network 

30 Manager 74 and Intelligent Routing 75. Access to 

network functionality is also provided through Report 
Requester 76, which provides a variety of detailed 
reports for the client/customer and a Message Center 77 



-12- 
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for providing enhancements and functionality to 
traditional e-mail communications. 

As shown in Figures 3 and 4 , the browser 
resident GUI of the present invention implements a 
5 single object, COBackPlane which keeps track of all the 

client applications, and which has capabilities to 
start, stop, and provide references to any one of the 
client applications. 

The backplane 12 and the client applications 

10 use a browser 14 such as the Microsoft Explorer- 

versions 4.0.1 or higher for an access and distribution 
mechanism. Although the backplane is initiated with a 
browser 14, the client applications are generally 
isolated from the browser in that they typically 

15 present their user interfaces in a separate frame, 

rather than sitting inside a Web page. 

The backplane architecture is implemented 
with several primary classes. These classes include 
COBackPlane, COApp, COAppImpl, COParm. and COAppFrame 

20 classes. COBackPlane 12 is an application backplane 

which launches the applications 54a, 54b, typically 
implemented as COApp. COBackPlane 12 is generally 
implemented as a Java applet and is launched by the Web 
browser 14 . This backplane applet is responsible for 

25 launching and closing the COApps. 

When the backplane is implemented as an 
applet, it overrides standard Applet methods initO, 
startO, stopO and run(). In the initO method, the 
backplane applet obtains a COUser user context object. 

30 The COUser object holds information such as user 

profile, applications and their entitlements. 'The 
user's configuration and application entitlements 
provided in the COUser context are used to construct 
the application toolbar and Inbox applications. When 

-13- 
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an application toolbar icon is clicked, a particular 
COApp is launched by launchAppO method. The launched 
application then may use the backplane for inter - 
application communications, including retrieving Inbox 
data. 

The COBackPlane 12 includes methods for 
providing a reference to a particular COApp, fpr 
interoperation. For example, the COBackPlane class 
provides a getAppO method which returns references to 
application objects. by name. Once retrieved in this 
manner, the application object's public interface may 
be used directly. 

As shown in Figure 2, the aforesaid objects 
will communicate the data by establishing a secure TCP 
messaging session witih one of the DMZ networkMCI 
Interact Web servers 24 via an Internet secure 
communications path 22 established, preferably, with a 
secure sockets SSL version of HTTPS. The DMZ 
networkMCI Interact Web servers 24 function to decrypt 
the client message, preferably via the SSL 
implementation, and unwrap the session key and verify 
the users session. After establishing that the request 
has come from a valid user and mapping the request to 
its associated session, the DMZ Web servers 24 will re- 
encrypt the request using symmetric encryption and 
forward it over a second socket connection 23 to the 
dispatch server 26 inside the enterprise Intranet. 

A networkMCI Interact session is designated 
by a logon, successful authentication, followed by use 
of server resources, and logoff. However, the world- 
wide web communications protocol uses HTTP, a stateless 
protocol, each HTTP request and reply is a separate 
TCP/IP connection, completely independent of all 
previous or future connections between the same server 

-14- 
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and client. The nMCI Interact system is implemented 
with a secure version of HTTP such as S-HTTP or HTTPS , 
and preferably utilizes the SSL implementation of 
HTTPS. The preferred embodiment uses SSL which 
5 provides a cipher spec message which provides server 

authentication during a session. The preferred 
embodiment further associates a given HTTPS request 
with a logical session which is initiated and tracked 
by a "cookie jar server" 2 8 to generate a "cookie" 

* 

10 which is a unique server-generated key that is sent to 

the client along with each reply to a HTTPS request. 
The client holds the cookie and returns it to the 
server as part of each subsequent HTTPS request. As 
desired, either the Web servers 24, the cookie jar 

15 server 28 or the Dispatch Server 26, may maintain the 

"cookie jar" to map these keys to the associated 
session. A separate cookie jar server 28, as 
illustrated in Figure 2 has been found desirable to 
minimize the load on the dispatch server 26. This form 

20 of session management also functions as an 

authentication of each HTTPS request, adding an 
additional level of security to the overall process. 

As illustrated in Figure 2, after one of the 
DMZ Web servers 24 decrypts and verifies the user 

25 session, it forwards the message through a firewall 25b 

over a TCP/IP connection 23 to the dispatch server 26 
on a new TCP socket while the original socket 22 from 
the browser is blocking, waiting for a response. The 
dispatch server 26 will unwrap an outer protocol layer 

30 of the message from the DMZ services cluster 24, and 

will reencrypt the message with symmetric encryption 
and forward the message to an appropriate application 
proxy via a third TCP/IP socket 27. While waiting for 
the proxy response all three of the sockets 22, 23, 27 
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will be blocking on a receive. Specifically, once the 
message is decrypted, the wrappers are examined to 
reveal the user and the target middle- tier (Intranet 
application) service for the request. A first -level 
5 validation is performed, making sure that the user is 

entitled to communicate with the desired service. The 
user's entitlements in this regard are fetched by the 
dispatch server 26 from StarOE server 49 at logon time 
and cached. 

10- If the requestor is authorized to communicate 

with the target service, the message is forwarded to 
the desired service's proxy. Each application proxy is 
an application specific daemon which resides on a 
specific Intranet server, shown in Figure 2 as a suite 

15 of mid- range servers 30. Each Intranet application 

server of suite 3 0 is generally responsible for 
providing a specific back-end service requested by the 
client, and, is additionally capable of requesting 
services from other Intranet application servers by 

20 communicating to the specific proxy associated with 

that other application server. Thus, an application 
server not only can offer its browser a client to 
server interface through the proxy, but also may offer 
all its services from its proxy to other application 

25 servers. In effect, the application servers requesting 

service are acting as clients to the application 
servers providing the service. Such mechanism 
. increases the security of the overall system as well as 
reducing the number of interfaces. 

30 The network architecture of Figure 2 may also 

include a variety of application specific proxies 
having associated Intranet application servers 
including: a StarOE proxy for the StarOE application 
server 39 for handling authentication order 
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entry/billing; an Inbox proxy for the Inbox application 
server 31, which functions as a container for completed 
reports, call detail data and marketing news messages, 
a Report Manager Proxy capable of communicating with a 
5 system- specif ic Report Manager server 32 for 

generating, managing and scheduling the transmission of 
customized reports including, for example: call usage 
analysis information provided from the StarODS server 
33; network traffic analysis/monitor information 

10 provided from the Traffic view server 34; virtual data 

network alarms and performance reports provided by 
Broadband server 35; trouble tickets for switching, 
transmission and traffic faults provided by Service 
Inquiry server 36; and toll free routing information 

15 provided by Toll Free Network Manager server 37. 

As partially shown in Figure 2, it is 
understood that each Intranet server of suite 30 
communicates with one or several consolidated network 
databases which include each customer's network 

20 management information and data. In the present 

invention the Services Inquiry server 3 6 .includes 
communication with MCI's Customer Service Management 
legacy platform 40(a). Such network management and 
customer network data is additionally accessible by 

25 authorized MCI management personnel. As shown in 

Figure 2, other legacy platforms 40(b), 40(c) and 40(d) 
may also communicate individually with the Intranet 
servers for servicing specific transactions initiated 
at the client browser. The illustrated legacy 

30 platforms 40 (a) -(d) are illustrative only and it is 

understood other legacy platforms may be interpreted 
into the network architecture illustrated in Figure 2 
through an intermediate midrange server 30. 



-17- 



SUBSTITUTE SHEET (RULE 26) 



WO 99/16230 PCT/US98/20137 



Each of the individual proxies may be 
maintained on the dispatch server 26, the related 
application server, or a separate proxy server situated 
between the dispatch server 26 and the midrange server 
5 30. The relevant proxy waits for requests from an 

application client running on the customer's 
workstation 10 and then services the request, either by 
handling them internally or forwarding them to its 
associated Intranet application server 30. The proxies 

10 additionally receive appropriate responses back from an 

Intranet application server 30. Any data returned from 
the Intranet application server 30 is translated back 
to client format, and returned over the internet to the 
client workstation 10 via the Dispatch Server 26 and at 

15 one of the web servers in the DMZ Services cluster 24 

and a secure sockets connection. When the resultant 
response header and trailing application specific data 
are sent back to the client browser from the proxy> the 
messages will cascade all the way back to the browser 

20 14 in real time, limited only by the transmission 

latency speed of the network. 

The networkMCI Interact middle tier software 
includes a communications component offering three (3) 
types of data transport mechanisms: 1) Synchronous; 2) 

25 Asynchronous; and 3) Bulk transfer. Synchronous 

transaction is used for situations in which data will 
be returned by the application server 4 0 quickly. 
Thus, a single TCP connection will be made and kept 
open until the full response has been retrieved. 

30 Asynchronous transaction is supported 

generally for situations in which there may be a long 
delay in application server 40 response. Specifically, 
a proxy will accept a request from a customer or client 
10 via an SSL connection and then respond to the client 
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10 with a unique identifier and close the socket 
connection. The client 10 may then poll repeatedly on 
a periodic basis until the response is ready. Each 
poll will occur on a new socket connection to the 
proxy, and the proxy will either respond with the 
resultant data or, respond that the request is still in 
progress. This will reduce the number of resource 
consuming TCP connections open at any time and permit a 
user to close their browser or disconnect a modem and 
return later to check for results. 

Bulk transfer is generally intended for large 
data transfers and are unlimited in size. Bulk 
transfer permits cancellation during a transfer and 
allows the programmer to code resumption of a transfer 
at a later point in time. 

Figure 5 is a diagram depicting the physical 
networkMCI Interact system architecture 10. As shown 
in Figure 5, the system is divided into three major 
architectural divisions including: 1) the customer 
workstation 20 which include those mechanisms enabling 
customer connection to the Secure web servers 24; 2) a 
secure network area 17, known as the DeMilitarized Zone 
"DMZ" set aside on MCI premises double firewalled 
between the both the public Internet 25 and the MCI 
Intranet to prevent potentially hostile customer 
attacks; and, 3) the MCI Intranet Midrange Servers 30 
and Legacy Mainframe Systems 40 which comprise the back 
end business logic applications. 

As illustrated in Figure 5, the present 
invention includes a double or complex firewall system 
that creates a "demilitarized zone" (DMZ) between two 
firewalls 25a, 25b. In the preferred embodiment, one 
of the firewalls 29 includes port specific filtering 
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routers, which may only connect with a designated port 
on a dispatch server within the DMZ. • The dispatch 
server connects with an authentication server, and 
through a proxy firewall to the application servers. 
5 This ensures that even if a remote user ID and password 

are hijacked, the only access granted is to. one of the 
web servers 24 or to intermediate data and privileges 
authorized for that user. Further, the hijacker may 
not directly connect to any enterprise server in the 
10' enterprise intranet, thus ensuring internal company 

system security and integrity. Even with a stolen 
password, the hijacker may not connect to other ports, 
root directories or applications within the enterprise 
system. 

15 The DMZ acts as a double firewall for the 

enterprise intranet because the web servers located in 
the DMZ never store or compute actual customer 
sensitive data. The web servers only put the data into 
a form suitable for display by the customer's web 

20 browser. Since the DMZ web servers do not store 

customer data, there is a much smaller chance of any 
customer information being jeopardized in case of a 
security breach. 

As previously described, the customer access 

25 mechanism is a client workstation 20 employing a Web 

browser 14 for providing the access to the networkMCI 
Interact system via the public Internet 15. When a 
subscriber connects to the networkMCI Interact Web site 
by entering the appropriate URL, a secure TCP/IP 

30 communications link 22 is established to one of several 

Web servers 24 located inside a first firewall 29a in 
the DMZ 17. Preferably at least two web servers are 
provided for redundancy and failover capability. In 
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the preferred embodiment of the invention, the system ■ 
employs SSL encryption so that communications in both 
directions between the subscriber and the networkMCI 
Interact system are secure. 
5 In the preferred embodiment, all DMZ Secure 

Web servers 24 are preferably DEC 4100 systems having . 
Unix or NT -based operating systems for running services 
such as HTTPS, FTP, and Telnet over TCP/IP. The web 
servers may be interconnected by a fast Ethernet LAN 

10 ' running at 100 Mbit/sec or greater, preferably with the 

deployment of switches within the Ethernet LANs for 
improved bandwidth utilization. One such switching 
unit included as part of the network architecture is a 
HydraWEB™ unit 45, manufactured by HydraWEB 

15 Technologies, Inc., which provides the DMZ with a 

virtual IP address so that subscriber HTTPS requests 
received over the Internet will always be received. 
The Hydraweb unit 45 implements a load balancing 
algorithm enabling intelligent packet routing and 

20 providing optimal reliability and performance by 

guaranteeing accessibility to the "most available" 
server. It particularly monitors all aspects of web 
server health from CPU usage, to memory utilization, to 
available swap space so that Internet/Intranet networks 

25 can increase their hit rate and reduce Web server 

management costs. In this manner, resource utilization 
is maximized and bandwidth (throughput) is improved. 
It should be understood that a redundant Hydraweb unit 
may be implemented in a Hot/Standby configuration with 

30 heartbeat messaging between the two units (not shown) . 

Moreover, the networkMCI Interact system architecture 
affords web server scaling, both in vertical and 
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horizontal directions. Additionally, the architecture 
is such that new secure web servers 24 may be easily 
added as. customer requirements and usage increases. 
The use of the HydraWEB™ enables better load 
5 distribution when needed to match performance 

requirements. 

As shown in Figure 5, the most available Web. 
server 24 receives subscriber HTTPS requests, for 
example, from the HydraWEB™. 45 over a connection 44a 

10 and generates the appropriate encrypted messages for 

routing the request to the appropriate MCI, Intranet 
midrange web server over connection 44b, router 5 5 and 
connection 23. Via the Hydraweb unit 45, a TCP/IP 
connection 3 8 links the Secure Web server 24 with the 

15 MCI Intranet Dispatcher server 26. 

Further as shown in the DM2 17 is a second 
RTM server 52 having its own connection to the public 
Internet via a TCP/IP connection 48. This RTM server 
provides real-time session management for subscribers 

20 of the networkMCI Interact Real Time Monitoring system. 

An additional TCP/IP connection 48 links the RTM Web 
server 52 with the MCI Intranet Dispatcher server 26. 

With more particularity, as further shown in 
Figure 5, the networkMCI Interact physical architecture 

25 includes three routers: a first router 49 for routing 

encrypted messages from the Public Internet 15 to the 
HydraWeb 4 5 over a socket connection 44; a second 
router 5 5 for routing encrypted subscriber messages 
from a Secure Web server 24. to the Dispatcher server 2 6 

30 located inside the second firewall 2 5b; and, a third 

router 65 for routing encrypted subscriber messages 
from the RTM Web server 52 to the Dispatcher server 26 
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inside the second firewall. Although not shown, each 
of the routers 55, 65 may additionally route signals 
through a series of other routers before eventually 
being routed to the nMCI Interact Dispatcher server 26. 
5 In operation, each of the Secure servers 24 function to 

decrypt the client message, preferably via~the SSL 
implementation, and unwrap the session key and verify 
the users session from the COUser object authenticated 
at Logon. 

■ 

10 After establishing that the request has come 

from a valid user and mapping the request to its 
associated session, the Secure Web servers 24 will re- 
encrypt the request using symmetric RSA encryption and 
forward it over a second secure socket connection 23 to 

15 the dispatch server 26 inside the enterprise Intranet. 

As described herein, the data architecture 
component of networkMCI Interact reporting system is 
focused on the presentation of real time (un-priced) 
call detail data, such as provided by MCI's TrafficView 

20 Server 34, and priced call detail data and reports, 

such as provided by MCI's StarODS Server 33 in a 
variety of user selected formats. 

All reporting is provided through a Report 
Requestor GUI application interface which support 

25 spreadsheet, a variety of graph and chart type, or both 

simultaneously. For example, the spreadsheet 
presentation allows for sorting, by any arbitrary set of 
columns. The report viewer may also be launched from 
the inbox when a report is selected. 

30 A common database may be maintained to hold 

the common configuration data which can be used by the 
GUI applications and by the mid-range servers. Such 
common data will include but not be limited to: 
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customer security profiles, billing hierarchies for 
each customer, general reference data (states, NPA's, 
Country codes), and customer specific pick lists:, e.g., 
ANI's, calling cards, etc.. An MCI Internet StarOE 
server will manage the data base for the common 
configuration of data. 

Report management related data is also 
generated which includes 1) report profiles defining 
the types of reports that are available, fields for the 
reports, default sort options and customizations 
allowed; and 2) report requests defining customer 
specific report requests including report type, report 
name, scheduling criteria, and subtotal fields. This 
type of data will be resident in an Inbox server 
database and managed by the Inbox server. 

The Infrastructure component of the nMCI 
Reporting system includes means for providing secure 
communications regardless of the data content being 
communicated. The nMCI Interact system security 
infrastructure includes: 1) authentication, including 
the use of passwords and digital certificates; 2) 
public key encryption, such as employed by a secure 
sockets layer (SSL) encryption protocol; 3) firewalls, 
such as described above with reference to the network 
architecture component; and 4) non- repudiation 
techniques to guarantee that a message originating from 
a source is the actual identified sender. • One 
technique employed to combat repudiation includes use 
of an audit trail with electronically signed one-way 
message digests included with each transaction. 

Another component of the nMCI Interact 
infrastructure includes order entry, which is supported 
by the Order Entry ("StarOE") server. The general 
categories of features to be ordered include: 1) Priced 
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Reporting; 2) Real-time reporting; 3) Priced Call 
Detail; 4) Real Time Call Detail; 5) Broadband SNMP 
Alarming; 6) Broadband Reports; 7) Inbound RTM; 8) 
Outbound RTM; 9) Toll Free Network Manager; and 10) 
5 Call Manager. The order entry functionality is 

extended to additionally support 11) Event -Monitor ; 12) 
Service Inquiry; 13) Outbound Network Manager; 14) 
Portfolio; and, 15) Client View. 

The Self -monitoring infrastructure component 

10 for nMCI Interact is the employment of mid- range 

servers that support SNMP alerts at the hardware level. 
In addition, all software processes must generate 
alerts based on process health, connectivity, and 
availability of resources (e.g., disk usage, CPU 

15 utilization, database availability) . 

The Metrics infrastructure component for nMCI 
Interact is the employment of means to monitor 
throughput and volumes at the Web servers, dispatcher 
server, application proxies and mid- range servers. 

20 Metrics monitoring helps in the determination of 

hardware and network growth. 

To provide the areas of functionality 
described above, the client tier 10 is organized into a 
component architecture, with each component providing 

25 one of the areas of functionality. The client- tier 

software is organized into a "component" architecture 
supporting such applications as inbox fetch and inbox 
management, report viewer and report requestor, TFNM, 
Event Monitor, Broadband, Real-Time Monitor, and system 

30 administration applications. Further functionality 

integrated into the software architecture includes 
applications such as Outbound Network Manager, Call 
Manager, Service Inquiry and Client. View. 
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The present invention focuses on the client 
and middle -tier service that enables customers to 
request, specify, and receive and view data pertaining 
to their toll free network management assets, e.g., 
5 toll free number routing plans, and to generate orders 

for changing aspects of the routing plans via a World 
Wide Web interface. 

As shown in Figure 6, the toll free network 
management tool 200 of the invention, referred to 

10 herein as "TFNM," implements a TFNM domain server 250 

which is one component part of a back-end MCI intranet 
infrastructure comprising above -described MCI's NetCap 
order entry system 240, Service Control Manager 241 
("SCM") and Data Access Points 242 ("DAP"). As will be 

15 described in greater detail, the TFNM tool 200 of the 

invention enables customers to change their toll-free 
network management plans , both in real - time and on a 
scheduled basis, via nMCI Interact 's web -based front - 
end and middle -tier infrastructure. Particularly, 

20 customer directives are entered by the user 100 via a 

TFNM graphic user interface. These directives are 
preferably communicated as Java applets over secure 
TCP/IP socket connections for input over the firewall 
25(b) to at least one secure server, e.g., a DM2 Web 

25 server that provides for authentication, validation, 

and session management. As will be described, the TFNM 
server 250 interfaces with the "NetCap" 240 mainframe 
system that provides user interface to the network 
control system, i.e., DAP switches 242 (Figure 6). The 

30 TFNM domain server 250 includes Java object classes 

whose methods are invoked by Java applets running on 
the customer browser. The browser Java applets 
specifically execute the customer directives by 
invoking certain methods on the TFNM Domain server 250. 

* 
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These Java objects additionally provide the interface 
functions to the NetCap 240. In the preferred 
embodiment, the Java objects at the TFNM domain server 
function as a proxy, and are invoked remotely 
implementing a Java remote method invocation "RMI" - like 
methodology. 

Particularly, as mentioned herein with 
respect to Figure 2, within the networkMCI Interact 
framework for producing Java applications over the 
Internet, there is provided common objects and an 
infrastructure allowing secure communications between a 
client (which resides on a browser) and a server (which 
resides safely within MCI's firewalls). As described, 
the security strategy includes: encrypting 
communication from the client to the web -server via SSL 
(HTTPS) and implementing HTTPS as the preferred method 
for allowing communication into the web server from the 
Internet; providing an additional firewall between the 
web -server and the dispatcher to allow only specific 
traffic from the web server to the dispatcher to occur; 
encrypting traffic between the web server and the 
dispatcher via DSA encryption; and enabling the 
dispatcher to validate all packets destined to internal 
MCI servers to ensure that they are from an 
authenticated client, and that a particular client has 
permission to communicate with a specific back-end 
server. To make this seamless for the client, a set of 
Common Objects performs this messaging. In the 
preferred embodiment, the invention implements a 
modified RMI which is referred to as "CORMI" (Common 
Objects RMI) which provides an RMI -like interface 
between the client and the server using the networkMCI 
Interact protocol. The CORMI procedures implemented 
have additional controls built in to provide the 
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necessary session security and maintenance for 
communication over the firewalls. 

More specifically, CORMI is MCI Interact' s 
protocol for providing secure, client- to -server 
5 communication with Java RMI--like semantics and 

comprises a library of Java classes used by. both the 
client applet and server application. In view of 
Figure 6, the communication path from the client and 
the server is as follows : 

10 The TFNM server application 250 registers 

remote objects with CORMI' s CORemoteSessionServer 
(analogous to Java RMI's Registry service) and then 
blocks waiting for connections. The TFNM client applet 
initiates communication by performing a logon through a 

15 COClientSession object. The COClientSession creates a* 

COSynchTransaction (an atomic unit of work based over 
an HTTPS socket) which connects to the MCI Interact 
system dispatcher server 235 (which is behind the outer 
firewall 25(b)). The dispatcher server 235 process 

20 validates the client's authorization . to logon (a 

process that involves contacting the StarOE service and 
generating a session key with a 'cookiejar' process) . 
After validating the client, the dispatcher uses a 
round- robin protocol to select a TFNM server and then 

25 opens an HTTPS connection to an instance of the TFNM 

server application. On this server, the 
CORemoteSessionServer creates a new session for this 
client and records the session key. 

A reply to a logon is sent back through the 

30 dispatcher to the client 100. The client then can do 

a lookup which results in a serialized remote interface 
of the remote object registered earlier being passed 
back to the client. The client can then use this 
remote interface as it would with Java RMI-doing remote 
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method invocations. The remote method invocations are 
handled by CORMI as COSynchTransactions through the 
dispatcher to the same TFNM server instance that the 
logon and interface lookup took place at. 
5 It should be understood that there is no 

permanent connection between the TFNM client and 
server; CORMI, through a COSynchTransaction, creates a 
new HTTPS connection to the dispatcher (and the 
dispatcher creates a connection to the TFNM server) for 

10 each unit of communication. 

As shown in the process flow diagram of 
Figure 7, a customer first types in the URL into the 
Web Browser where a connection is made to the 
networkMCI Interact web page, as indicated at step 302. 

15 Having accessed the web page, the user logs in, as 

indicated at step 305, and a user Common Object is 
created. At this point, a message is sent via an 
established HTTPS connection via a Dispatcher Server 
235 (Figure 6) to the StarOE Server 260 to validate the 

20 customer as indicated at step 307. Once the customer 

is validated, at step 308a,b, the backplane objects 
request a list of all the authorized applications from 
the StarOE server, as indicated at step 310. At steps 
312 and 314 respectively, a networkMCI Interact applet 

25 is downloaded to the customers Web Browser via the 

established HTTPS connection, and the browser presents 
the customer with the networkMCI Interact systems home 
page, such as the exemplary home page 29 2 shown in 
Figure 8. It should be understood that in the 

30 preferred embodiment., the icons for applications the 

user has security access to are shown bolded. 
Referring back to Figure 7, at step 314, the customer 
selects the TFNM application from the home page by 
clicking on a Network Manager icon 293 (Fig. 8) after 
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StarOE validates the user's id and password. The 
backplane object allows the user access to the TFNM 
front end if the user is so authorized. As shown at 
step 316, a client TFNM application is downloaded to 
5 the customer who is presented with the TFNM . screen , as 

indicated at step 318. An exemplary TFNM web-page 
display 294 is shown in Figure 9 (a) which presents a 
variety of TFNM file menu options including: 1) an 
option 295 enabling a user to select a Corp ID, i.e., a 

10 corp, set, number, and plan to establish a working 

environment; 2) an option 296 enabling a user to cut- 
through to a 3270 mainframe NetCap application; 3) an 
option 297 enabling a user to Implement Plan, i.e., put 
a plan in use by creating an IMPL order; and, 4) an 

15 option 29 8 enabling a user to modify the termination of 

a routing plan by creating a QUIK order. As further 
shown in Figure 9 (b) , the open menu includes a Plan 
option 285 which allows the user to select from a list 
of plans in the current working environment and enables 

20 opening of the plan in a graphical mode on a VORT 

("View Only Routing Tree"), as will be explained; and a 
Tree View option 286 which displays the last plan 
accessed on the VORT screen. As further shown in 
Figure 9 (c) , the report menu includes an option 287 for 

25 allowing the user to set up and execute an order filter 

query which results in the display of an order list, as 
will be hereinafter described in greater detail. Thus, 
referring back to Figure 7, at step 321, the customer 
is enabled to select a view of his/her routing plans in 

30 accordance with that user's privileges. To determine 

privileges, as indicated at step 326, TFNM user 
security profile information is requested from StarOE 
that comprises a list of Corp Ids and Accessld 
combinations, referred to herein as "RACF ID" 
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combinations that the customer is allowed to access 
within TFNM. Particularly, user security profile 
elements obtained from StarOE include: Corp Id, i.e., 
the Corporation Id the customer user has access to 
5 within StarOE; and Defaultlnd , i.e., a default Corpld 

indicator having, for example, ' Y' or ' N' values. 

Once the customer has logged into TFNM and 
has received the StarOE security message, a 
communication is made from the TFNM server 2 50 to 

10 NetCap 240, as indicated at step 328, requesting a user 

security profile. Particularly, the messaging system 
implemented for all communications between the TFNM 
server and NetCap is referred to herein as "Registry". 
Security from NetCap is by Racf Id and Corp Id. For 

15 each Corp Id a user has access to, that user must have 

a Racf Id. If a user has Enterprise level security, 
then the list of Corps under that Enterprise within 
NetCap have the same security as the Enterprise. 
Particularly, in response to a user login, in the 

20 preferred embodiment, a TFNM server application is 

executed. From this application, the TFNM server 
instantiates a Profile Manager Java object which is 
registered with CORMI and called upon to invoke further 
k objects relating to the following: user profile, e.g., 

25 preferences, user security profiles, i.e., for tracking 

customer entitlements/privileges including rights for 
creating or modifying specific TFNM routing plans or 
generating QUIK or IMPL orders; and, session 
management, i.e., objects which encapsulate the state 

30 and behavior associated with a specific user login, 

e.g., time logged in. 

In the preferred embodiment, once profile 
manager is instantiated at step 328, the TFNM server 
additionally instantiates objects related to view 

• 
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screens and options according to the user's 
entitlements/privileges. Specifically, a Corporation 
Manager ( "CorpMngr" ) object is invoked to enable the 
user to select the corporation having the desired 
routing plan to be looked at. Then, the following 
objects are sequentially invoked: a Set Manager object 
for the corporation selected? a Number Manager object 
that knows the TFNM numbers (e.g., l-800/8xx) belonging 
to the Set and/or Corp; and, a Plan Manager object, 
which knows the routing plans that belong to the 
selected corporation, set, and/or number selected by 
the user up to that point. It should be understood 
that the TFNM server is enabled to communicate with 
NetCap server for this data if not provided in the TFNM 
database, or, if the information in TFNM is not 
current. For instance, for some messages, a data sync 
may always be invoked. Thus, TFNM may contact NetCap 
and pass date and time stamps indicating the last 
update for the record. If NetCap determines that they 
have later data version, it will pass down the updated 
version, otherwise, it will pass an empty message back 
to TFNM. Alternately, an internal table 245, as shown 
in Figure 6, may be accessed indicating the intervals 
for data record updates and which will indicate the 
last time a data sync was performed for a particular 
record. By checking this table, a determination may be 
made as to whether contact must be made to NetCap for a 
data update. 

In the preferred embodiment, as shown in 
Figure 6, the TFNM server 250 communicates a plan/data 
sync message 243 via Registry messaging to NetCap. 
Appendix A illustrates the Registry message call 
"NPSNC" which is the request to sync a plan and 
transmitted from the TFNM server to NetCap. A variety 
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of Registry response messages for this request is 
provided in Appendix B. 

As shown in Figure 10, the File/Select Corp 
ID menu option causes a screen to be displayed that 
5 enables the user to select elements (Corp ID, Set ID, 

Routing Number) that invoke objects for establishing a 
working environment, or, to select a plan for view. 
The data elements displayed on this screen differ 
according to the type of plan chosen. In the preferred 

10 embodiment, the TFNM Network Manager 200 enables the 

customer to create or modify orders for four types of 
TFNM routing plans: a Number Level Plan ( "NLP" ) , Super 
Routing Plans ("SRP"), Enhanced Voice Service Routing 
plans ("EVS"), and universal routing plans ("URP"). As 

15 shown in Figure 10, Number Level, EVS, or Super Routing 

plan radio buttons 265 may be selected to access 
corresponding visible screen elements. When an NLP 
plan is selected, for instance, the following elements 
are displayed: a Corp ID element 266 which is a single 

20 selection list box that becomes populated with corp 

id' s available to the user in accordance with that 
user's entitlements; a Set ID element 267 which is a 
single selection list box populated with Set ID's that 
the user has security access to for a chosen Corp ID; a 

25 Number list box element 268 which is a single selection 

list box populated with number information for the 
indicated corp. /set; and, a Plan list box 269 which is 
a single selection list box populated with plan 
information such as: a plan description, plan in use, 

30 or when the plan was last modified, for the selected 

number. It should be understood that corporate 
security is obtained from NetCap whenever a new Corp ID 
is selected, in the manner described. 
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In the preferred embodiment, using additional 
buttons 262, 263 and 264 from the screen shown in 
Figure 10, the user respectively, is enabled to open or 
close the "plan" portion of the. screen; save the 
selected corp/set/number/plan id as the user's current 
working environment; and/or display a tree -view of the 
highlighted plan. 

When the user chooses to view a selected 
routing plan, and after verifying security with both 
StarOE and NetCap, the TFNM server may execute the 
synch process with NetCap 240, as indicated at step 
33 0, Figure 7 and described above. During this 
process, TFNM updates any records in the TFNM server 
copy of the customer's chosen routing plan with changes 
that were made in NetCap since the user last accessed 
the system. The TFNM server database is updated with 
the latest routing plan information for that customer, 
and the updated routing plan information is sent to the 
user, as indicated at step 333. The customer is now 
presented with the requested routing plan view at step 
335 via the TFNM client application, as shown in Figure 

A user may view a routing plan in several 
formats, e.g., a hierarchical tree graphic or a 
spreadsheet. In the preferred embodiment, as shown in 
the exemplar screen display of Figure 11, the Routing 
Plan is displayed as a tree structure comprising of a 
series of linked node types in a specific hierarchy. 
As shown in Figure 11, the screen is divided into two 
main sections: a first section 272 comprising the 
graphical representation of the routing tree having 
nodes tree branches that can be expanded and collapsed; 
and, a second section 273 for displaying the details of 
the currently highlighted tree node. The node types 
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that are available include: 1) a Plan node 276a which 
is shown highlighted in Figure 11 and details the 
features for the plan; 2) an Origination node ("ORIG") 
276b which details the geographical elements used in 
5 determining where to route the call. Multiple 

Origination nodes may exist under a plan node; 3) a Day 
of Week node ( "DOW" ) 276c which details how to route 
calls based on days of the week. Multiple Day of Week 
nodes may exist under an Origination and all seven days 

10 of the week must be accounted for under each 

origination; 4) a Time of Day node ("TOD") 276d which 
details specific time ranges for routing calls. 
Multiple Time of Day nodes may exist under a Day of 
Week and all 24 hours of the day must be accounted for 

15 under each Day of Week; and, 5) a Percent Logical 

Termination node ("%LTERM") 276e which details where 
the calls terminate and at what percentage of the time. 
As shown in Figure 11, multiple %LTERM nodes may exist 
under a Time of Day. The percentages in "sibling" nodes 

20 must add up to 100 percent. A user can select details 

of any node by clicking or scrolling. Trigger Points 
(not shown) may also be displayed as children of the 
node they ride on. For example, a Trigger Point that 
rides on an Origination node would be displayed under 

25 the Origination on the same level as a Day -of -Week 

node. At each node, decisions related to the call 
routing are executed. 

As shown in Figure 11, for a plan node, the 
corresponding plan detail screen 273 is populated with 

30 the existing plan description; the Orig id of the 

default orig on the plan; and Origination Features 
having values derived based on the features in use on 
the plan. Likewise, for an origination node 276b, the 
corresponding plan detail screen displays: the ID of 
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the highlighted origination node and the corresponding 
description including listboxes displaying the 
geographic elements (countries, states, area codes and 
exchanges) associated with the highlighted Origination 

■ 

5 node. For the DOW node 276c, the corresponding plan 

detail screen displays the Day Id of the DOW node and 
the list of days associated with the DOW node. For the 
TOD node 276d, the corresponding plan detail screen 
displays the list of time ranges associated with the 

10- TOD node. For the Termination node 276e, the 

corresponding plan detail screen displays: the ID of 
the termination associated with the highlighted node; a 
description of the termination associated with the 
highlighted node; an indication of whether a cross corp 

15 term is associated with the highlighted node, and, if 

the Cross Corp Term indicator is ''Yes," a field 
displaying the cross corp Id associated with the 
termination in the Termination ID field; and an 
indication of the percentage of calls allocated to this 

20 termination node. Further details may be displayed 

including a Details tab (not shown) for displaying: the 
customer service id associated with the termination; 
the activation date of the termination; the activation 
date received associated with the termination; the 

25 service status associated with the termination; the 

Switch Trunk ID associated with the termination; and, 
an indication of whether the termination is EVS; 
whether the Termination has a real-time ANI Delivery 
and, the activation date for the Real Time ANI. 

30 Additionally, an ANI tab (not shown) may be displayed 

for presenting the user with information as to whether 
the termination has an Automatic Number Identifier 
CANI"), the country code associated with the 
termination and the Termination ANI. An "Overflow" tab 

-36- 



SUBSTITUTE SHEET (RULE 26) 



WO 99/16230 PCT/US98/20137 



of the termination details screen displays • for the 
user: a network call redirect indicator indicating 
whether the termination has an NCR; a direct 
termination overflow indicator indicating whether the 
5 termination has a DTO. Likewise, a "DNIS" tab (not 

shown) may be displayed for presenting the -user with 
information as to whether DNIS/Enhanced DNIS is active 
on the termination; the date that DNIS is activated; an 
indication of whether the Dialed Digit Outpulsing (DDO) 

10 is active on the termination; the prefix digits used 

for DNIS, and the number of digits to be reused for 
DNIS. Finally, an "International Outbound" tab (not 
shown) may be displayed for presenting the user with 
information as to whether international outbound is 

15 active on the termination; the Country code associated 

with the termination if international outbound is 
active; the Carrier code associated with the 
termination if international outbound is active; and 
the free phone number associated with the termination 

20 .if international outbound is active. 

Via the TFNM Client Application, the user is 
now able to invoke TFNM functions such as the "IMPL" 
depicted in Figure 6 as the IMPL request 22 2 which 
enables the user to quickly change the number routing 

25 plan that a working number or set of working numbers is 

routing to; or "QUIK" depicted in Figure 6 as the QUIK 
request 224 which enables the user to quickly add, 
change and/or delete one or more termination locations, 
and/or change the percentage allocation of two or more 

30 of these locations, for a currently implemented routing 

plan. In accordance with the present invention, 
additional directives may include: a temporary ( ''TEMP" ) 
IMPL directive which is created in conjunction with an 
Impl by entering a roll -back date so that the routing 
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plan will revert to its prior use status prior to 
creation of the Impl; and a TEMP QUIK directive which 
enables roll -back of the changes made by a QUIK order 
to what they were before the QUIK. 
5 Referring back to Figure 7, for the case when 

a user desires to implement the IMPL/TEMP IMPL plan, or 
the QUIK/TEMP QUIK, the user selects the Setup IMPL 
from the TFNM screen at step 340. Specifically, the 
TFNM Client application causes the instantiation of an 

10 "Order Manager" object which invokes methods capable of 

accessing all the information pertaining to orders for 
a given corp id, set, TFNM telephone number and plan. 
An order comprises two components: 1) an order 
administration record comprising data such as: order 

15 status, effective data time and order number, etc.; 

and, 2) order administration detail record which 
includes the detailed inf ormation pertaining to that 
order, e.g., changes to percent allocation or effective 
dates/ times etc. for a plan, etc. The Order Manager 

20 object includes an ImplOrder sub- class which knows 

about IMPL orders, e.g., IMPL functionality, and 
invokes objects to obtain order records, pertaining to 
plans. As mentioned, an IMPL order allows a user to 
change which routing plan they want to be "in use" for 

25 a specific number or a set of numbers. 

Figure 12 illustrates the IMPL dialog screen 
2 55 enabling the user to generate a TEMP IMPL/IMPL 
order for the desired Corp Id. Particularly, as shown 
in Figure 12, a number/set selection dialog box 251 is 

30 displayed having radio buttons enabling selection of 

the desired 800/8xx Number, a set of numbers, a 
reserved number; or, an EVS Number for implementing an 
EVS plan. Selection of one of these will invoke a 
"data controller" object for retrieving information 

-38- 



SUBSTITUTE SHEET (RULE 26) 



WO 99/16230 



PCT/US98/20137 



from a TFNM database causing a corresponding dialog to 
appear enabling user search for the desired 800/8xx 
Number, set, reserved number, or EVS Number for the 
desired Corp Id. After selecting the desired number or 
5 set, the user is prompted to select from dialog box 252 

the specific plan type that is to be IMPL'd..for the 
number or set. As shown, the dialog box 252 comprises 
radio buttons enabling user selection of the desired 
plan IDs including, but not limited to, a Number Level 

10 Plan ("NLP") implemented for an 800/8xx Number or a set 

of numbers, a Super Routing Plan (SRP) implemented for 
an 800/8xx Number, a set of numbers, or a reserved 
number; and, an EVS plan implemented for an EVS Number. 
User selection of the plan is illustrated at step 345, 

15 Figure 7. It should be understood that if the user has 

privileges for only one Corp ID, the system will select 
only the plans associated with that Corp ID for the 
user. If the user has privileges for more than one 
Corp ID, the user is presented with a list of all Corp 

20 IDs and will select one Corp ID. Any subsequent 

actions the user takes within the application are 
applicable to that selected corporation. 

After having selected the Corp, set, Routing 
Plan Number or Routing Plan ID, the user may set or 

25 modify the routing as indicated at step 350. In the 

preferred embodiment, the user can define the routing 
plan according to any of the above- described options: 
Origin, Country, State, NPA, NXX, Day of week, Time of 
day, and Termination, as indicated at step 360. These 

30 options can be defined for each Corp ID, Set or number. 

In the preferred embodiment, the user is enabled to 
implement NLPs, SRPs, and EVSs and URPs for a selected 
toll free number or, implement NLPs and SRPs for a set 
of numbers that they want routed differently. Via IMPL 
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request messaging, the user selects the desired routing 
plan for the number/set and the desired date and time 
when they want to start routing the number to the 
selected plan and forwards the request to the TFNM 
server via HTTPS messaging as indicated at step 3 55 
(Figure 7) . 

As shown in Figure 6, the customer's Send 
IMPL request 222 is communicated over the HTTPS 
connection as a request to invoke methods in the Order 
Manager class/sub-classes via CORMI . Once the plan has 
been submitted to the TFNM server via the send IMPL 
message 222, the TFNM server receives the new routing 
plan and verifies the user's security with NetCap, as 
indicated at step 360 (Figure 7). Once the user's 
security has been verified, the TFNM server submits the 
IMPL request to NetCap 240 via Registry messaging, as 
indicated at step 365. Particularly, the Order Manager 
classes/sub- classes execute methods for translating the 
IMPL order in a form suitable for submission to NetCap. 

Appendix A illustrates the Registry message 
calls that are transmitted from the TFNM server to 
NetCap for the IMPL/TEMP IMPL order and the 
corresponding NetCap responses. Included is the 
message for submitting an IMPL order (NIMPL) to NetCap. 

It should be understood that, in the case of 
a user implementing a TEMP IMPL request, the user 
follows the same procedure as for the IMPL order, e.g., 
selecting the desired routing plan for the number/set 
and Corp Id. However, as shown in Figure 12, the user 
is presented with a dialog 253 for submitting the 
desired date and time when the user wants to start 
routing the number to the selected plan, and, a dialog 
254 for submitting the roll back date and time when 
they want the previous routing plan to be effective 
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again. Thus, in accordance with the sequence of Figure 
7, both an IMPL and TEMP IMPL message pair is sent to 
the TFNM server for processing as described, herein. 

After a TEMP IMPL and/or IMPL request has 
5 been transmitted to NetCap 240, it is stored for future 

implementation. In view of Figure 6, NetCap sends an 
acknowledgment via Registry messaging back to the TFNM 
server. 

Appendix B illustrates the Registry message 

10 calls that are transmitted to the TFNM server from 

NetCap in response to the submitted IMPL order. 
Included is the message indicating successful 
processing of the IMPL request (NSUCS) and the message 
indicating completion of the order in NetCap (UCOMP) . 

15 The TFNM server passes this information on to the user 

via CORMI messaging over the HTTPS connection. If the 
user is still logged on, this acknowledgment appears as 
a pop- up message on their screen, as indicated via line 
226 in Figure 6. If the user has logged off, TFNM 

20 retains the acknowledgment that the IMPL has been 

received and saved for the next user logon. Likewise, 
when an IMPL has been transmitted to NetCap and either 
implemented or terminated, NetCap sends a registry 
message back to the TFNM server which, in turn, passes 

25 this information back to the user via HTTPS 

connec t i vi ty . 

Referring back to Figure 7, at step 340, the 
user may instead desire to execute the QUIK feature 
that enables customers to quickly add, change and/or 

30 delete one or more termination locations (nodes) , 

and/or change the percentage allocation of two or more 
of these locations, for a currently implemented routing 
plan, Figure 13 illustrates an exemplary web-page 
screen 4 00 instantiated by the TFNM client application 
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for the QUIL/TEMP QUIK order process which is presented 
to the user. As shown in Figure 13, there is provided 
a number of radio buttons which the user may select: 1) 
an 800/8xx number button 402 which causes a dialog to 
be displayed for enabling the user to enter or select 
an 800/8xx number from a list of 800/8xx #Ls (not 
shown) having an associated "plan in use." Once the 
800/8xx # is entered, the system returns the 
corresponding NLP or SRP Plan in use; 2) an SRP button 
404 which causes a- dialog to be displayed for enabling 
the user to enter or select an SRP Id from a list (not 
shown) . Once entered, the system returns the SRP 
Routing Plan for the SRP Id; 3) an EVS button 406 which 
causes a dialog to be displayed for enabling the user 
to enter or select an EVS number. Once entered, the 
system returns an EVS Plan In Use if available. In 
each dialog, a corresponding "data controller" object 
is invoked for retrieving information from a TFNM 
database causing a corresponding dialog to appear 
enabling user selection. 

After selecting the desired plan, the user is 
required to key or select each of the following 
buttons: Origination Id/Description 407, Day of Week 
Id/Desc. 408, and Time Begin/Desc. 409. Selection of 
the Origination Id/Description button 407 causes a list 
of Origination Id and corresponding descriptions to be 
displayed. In this manner a user may scroll through 
the list and identify the branch comprising the 
terminations that are to be modified. Likewise, 
selection of the Day of Week Id/Desc. button 408 causes 
a list of Day of Week node ids/descriptions to be 
displayed for the selected Origination Id node, and 
through which the user may scroll through and select 
for modification. Similarly, selection of the Time 
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Begin button 409. causes a list of Time of Day node 
ids/descriptions to be displayed for the selected DOW 
and through which the user may scroll through and 
select for modification. Through use of the Order 
5 Manager classes/sub-classes the system auto-populates 

the Orig, DOW, TOD, and, once populated, the system 
displays in display field 412 the Lterms for the TOD 
node which comprise the terminations and percent 
allocations. In the preferred embodiment, the user may 

10 change percentage allocations by overtyping the amount 

or using the spin box up/down arrows 410 (increments of 
1 percent) . The user may additionally modify the 
percentages for the remaining termination (s) as long as 
the sum of the percentages for all the terminations 

15 attached to the selected Time interval node equals 100 

percent. Action keys 415a-415d may additionally be 
enabled for user selection in accordance with 
enterprise business rules and/or user security. 
Specifically, key 415a enables the submission of the 

20 QUIK/TEMP QUIK order to NetCap for approval (Issue 

key) . Key 415b allows the user to add a termination 
to the TOD node (including cross -corp terms that the 
customer has cross corp agreements with) , or change the 
termination id, description, or percent allocated to " 

25 the termination for this plan. Preferably, selection 

of key 415b enables display of a web page having a 
Termination screen enabling these choices. Key 415c 
enables the user to select the termination that the 
user wants replaced and presents the user with the 

30 Termination screen to select the term for change 

(Change Term key) . The key 415d enables the user to 
select the term they want to delete on the selected 
routing branch. In the preferred embodiment, the system 
defaults effective date/time to the current date/time, 
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however, the user may enter a future rollback date/ time 
up to 1 year in the data and time entry fields 416a,b 
in Figure 13. If the user enters a Rollback date/time 
in the rollback date fields, the system generates a 
5 TEMP QUIK order that sets the Routing Plan back to its 

state before the QUIK order. Preferably, the Rollback 
date/time may not be greater than 1 year in the future. 

Thus, from the dialog box 4 00 (Figure 13) , 
the user is enabled to perform the following: 1) change 
10 one or more terminations for NLP or SRP; 2) replace one 

4 

or more terminations on an EVS Routing Plan; 3) change 
the percent allocation of currently implemented NLP, 
EVS, or SRP Plan; 4) add one or more terminations to 
the currently implemented NLP or SRP Plan; 5) add one 

15 or more terminations to an EVS Routing Plan; and, 6) 

delete one or more terminations from the currently 
implemented plan of an NLP, EVS or SRP Plans. It 
should be understood that, in the case of a user 
implementing a TEMP QUIK request, the user selects the 

20 desired routing plan for the number/set, the desired 

date and time when they want to add, change and/or 
delete one or more termination locations and/or 
percentage allocation of these locations for a 
currently implemented routing plan, and, optionally, 

25 the roll back date and time when the changes are to 

revert back to their original settings. Thus, a QUIK 
and TEMP QUIK message pair is sent to the TFNM server 
for processing as described herein. 

Referring back to Figure 6, the customer's 

30 Send QUIK request 224 is communicated by the TFNM 

client applet by communication between the Dispatcher 
server 235 and the TFNM server objects using CORMI . 
The Object manager/sub-classes execute methods for 
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translating the QUIK/TEMP QUIK order in a form suitable 
for submission to NetCap. 

Appendix A also illustrates the Registry- 
message calls that are transmitted from the TFNM server 
5 to NetCap for the QUIK/TEMP QUIK order and the 

corresponding NetCap responses. Included is the 
message for submitting an QUIK order (NQUIK) to NetCap. 

Once the plan has been submitted to the TFNM 
server via the send QUIK message, the TFNM server 

10 receives the new routing plan and verifies the user's 

security with NetCap. Once the user's security has 
been verified, the TFNM server submits the QUIK request 
to NetCap 24.0 via Registry messaging. 

After a TEMP QUIK and/or QUIK request has 

15 been transmitted to NetCap, it is stored for future 

implementation. In view of Figure 6, NetCap sends a 
registry message to the TFNM server acknowledging that 
the request has been stored. 

Appendix B also illustrates the Registry 

20 message calls that are transmitted to the TFNM server 

from NetCap in response to the submitted QUIK order. 
Included is the message indicating successful 
processing of the QUIK request (NSUCS) and the message 
indicating completion of the order in NetCap (UCOMP) . 

25 The TFNM server then passes this information on to the 

user via CORMI messaging over the HTTPS connection. If 
the user is still logged on, this acknowledgment 
appears as a pop -up message on their screen, as 
indicated via line 226 in Figure 6. If the user has 

30 logged off, TFNM retains the acknowledgment that the 

QUIK order has been received and saved for the next 
user logon. Likewise, when a QUIK has been transmitted 
to NetCap and either implemented or terminated, NetCap 
sends a registry message back to the TFNM server which, 
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in turn, passes this information back to the user via 
CORMI. 

As described, a change to a routing plan is 
saved locally before being submitted to NetCap. The 
submission happens when the plan changes are converted 
into an approved order having an approved o_rder admin 
record and with a condition that NetCap has no 
preceding orders queued against the plan. The 
submission process takes place in two steps: first, the 
order admin record is sent to NetCap immediately, and 
second, when no orders are pending against the plan, 
the order admin detail record is then sent. The delay 
results because NetCap does not queue more than one 
order against a plan at a time. The TFNM server is 
configured to hide this limitation by stacking orders - 
a process of accepting multiple submissions and queuing 
them internally for later transmission to NetCap; The 
order admin record is sent immediately. The order 
admin detail record is sent soon as possible 
thereafter. 

Further functionality provided by the TFNM 
server is the ability to open plans, i.e., display a 
list of routing plans under the current working 
environment for display as a VORT (Figure 11) , or, view 
orders and filter through orders. Particularly, the 
TFNM client will instantiate the Order Manager object 
which instantiates order administration detail objects 
and other objects for retrieving administrative records 
comprising the details for a particular order in the 
TFNM database. For example, selection of the Report 
Order menu option shown in the screen display of Figure 
9(c), will cause the display of an order filter screen 
enabling a user to enter elements that they would like 
to use to query for orders and submit order queries. 
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The results of an order query are displayed in an order 
select list 420, such as shown in Figure 14. From this 
list, a user can retrieve details pertaining to an 
order, or, change an order's status or update remarks. 
Particularly, from an administration button 422, the 
user is presented with a dialog 425 as shQwn in Figure 
15, for example, enabling the user to update the order 
status and the effective date/ time. It is from these 
dialogs that a user may select a button 423 to un- 
approve an order (if the selected order has been 
approved by NetCap) and, a button 424 to "zap" (delete) 
an existing order. 

Appendix A illustrates the Registry message 
calls that are transmitted from the TFNM server to 
NetCap for un- approving an order (NOUAP) , zapping an 
order (NOZAP) , and, requesting pending order data 
(NPIUO) . Corresponding NetCap responses are provided 
in Appendix B. 

It should be understood that, in accordance 
with the principles described herein, the TFNM 
management tool of the invention is capable of 
supporting "feature" orders, i.e., functionality 
enabling customers to add a new TFN routing plan, e.g., 
NLP, SRP, URP, or EVS, or, change other the attributes 
or structure of an existing plan, e.g., changing 
attributes of a routing plan directly from the VORT 
(Figure 11) . The TFNM tool additionally may provide 
"drag and drop" enabling users to configure routing 
elements between plans. 

The foregoing merely illustrates the 
principles of the present invention. Those skilled in 
the art will be able to devise various modifications, 
which although not explicitly described or shown 
herein, embody the principles of the invention and are 
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thus within its spirit and scope. For instance, 
although, the web/Internet network management tool 
described herein is described with respect to 
customer's toll-free, e.g., 1 - 800 /8xx networks, the 
5 principles may be readily applied to other types of 

telecommunications networks. 
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APPENDIX A 
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From 


NOUAP 




Unapprove an order 


From 


NOZAP 




Zap an order 


From 


NPIUO 


DPIUO 


Request the plan in use and pending 
order data for a specific number. 


Fmm 




DSORG 

DSDAY 

DSTIM 

DSPCT 

DSHOL 

DSCTY 

DSSTA 

DSNPA 

DSNXX 


Kequest a plan sync, it tne plan nas 
changed since the date/time given, the 
plan is downloaded. If the plan is up to 
date as of the date/time given, an 
NSUCS message is returned. 


f 




NSUCS 
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From or 
To 

TFNM 


Message 
ID 


Response(s) 
to or from 


Commenis 


From 


NQIKS 


NSUCS 
UCOMP 


Percentage allocation order for a Super 
Routing Plan. 

NSUCS is returned when NctCap 
accepts the order. 

UCOMP is sent unsolicited when once 
the order completes. 


From 


NQUIK 


NSUCS 
UCOMP 


Percentage allocation order for a 
Number Level Plan. 
NSUCS is returned when NetCap 
accepts the order. 

UCOMP is sent unsolicited when once 
the order completes. 


From 


NRON 


DRON 


Request for an unused NetCap order 

iiuinucr 


From 


NSRLS 


DSRLS 


Request list of SRP's for a corp. 


From 


NSSN 


DSSN 


Request a list of toll free numbers for a 
set 


From 


NSSU 


DSSU 


Request a list of users for a set 


From 


NSSY 


DSSY 


Reuest a list of sets for a set, or the 
whole set structure 


From 


NSTAT 


DSTAT 


Request a routing number status 
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APPENDIX B 



To 

TFNM 


D8PL2 


N8PLS 


Number Level Plan list for a number 


To 


D8PLZ 


N8PL2 


Number Level Plan list for a set 


To 


DCCLS 


NCCLS 


Cross corp list for a corp 


To 


DCNXX 


NCNXX 


All NXX's or the NXX's for one NPA. 


To 


DCSE 


NOGON 


Fuction level security list for a user. 


To 


DED 


NED 


Corp list for an enterprise. 


To 


DEPLS 


NEPLS 


EVS plan list for a routing number or for 
a corp. 


To 


DERR 


Any 


Error processing a request. 
Currently the body version number 
matches the body verion of the message 
that was sent to NetCap that instigated 
the error. NetCap messaging is changing 
this so that TFNM will currently only 
use body version 02. Other version 
numbers will be used later if the message 
format needs to change. 


To 


DERR 






To 


DERR 






To 


DERR 






To 


DIMPL 




Not used, NetCap sends an NSUCS 
instead. 


To 


DIMPS 




Not used, NetCap sends an NSUCS 
instead. 


To 


DLNOR 


NLNOR 


Non-pending orders for a corp. 


To 


DLPOR 


NLPOR 


Pending orders for a corp. 


To 


DLTRM 


NLTRM 


Lterm detail for a corp. 


To 


DPIUO 


NPIUO 


Plan in use and pending order data for a 
specific number. 


To 


DRON 


NRON 


An unused NetCap order number . 


To 


DSCTY 


NPSNC 


Plan Sync - Origination Country data 


To 


DSDAY 


NPSNC 


Plan Sync - Day of week data 


To 


DSHOL 


NPSNC 


Plan Sync - Holiday data 


To 

• 


DSL8R 


NIMPL 
NIMPS- 

• 


When the implement order is for a set of 
numbers, this response contains a list of 
the numbers that will and will not be 
included in the order for the set 
requested. 


To 


DSNPA 


NPSNC 


Plan Sync - Origination NPA data 


To 


DSNXX 


NPSNC 


Plan Sync - Origination NXX data 


To 


DSORG 


NPSNC 


Plan Sync - Origination data 


To 


DSPCT 


NPSNC 


Plan Sync - Percentage allocation data 


To 


DSPLN 


NPSNC 


Plan Sync - Plan data 


To 


DSRL2 


NSRLS 


List of super routing plans for a corp 


To 


DSSN 


NSSN 


List of numbers for a set 


To 


DSSTA 


NPSNC 


Plan Sync - Origination state data 


To 


DSSU 


NSSU 


List of users for a set 


To 


DSSY 


NSSY 


Set list for a corp, or sets list for a set 


To 


DSTAT 


NSTAT 


Status for a routing number 


To 


DSTTM 


NPSNC 


Plan Sync - Time of Day data 
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To 


DVENT ■ 






To 


DVENT 






To 


DVENT 






1 O 








1 0 




TsJTVXDT 
NTMPS 

NQIKS 
NQUIK 
NPSNC 
Etc. 


oucccss receiving or processing a 

Currently the body version number 
matches the body verion of the message 
that was sent to NetCap that instigated 
this response. NetCap messaging is 
changing this so that TFNM will 
currently only use body version 02. 
Other version numbers will be used later 
if the message format needs to change. 


To 


NSUCS 






To 


NSUCS 






To 


NSUCS 






To 


UCOMP 


NQIKS 
NQUIK 
NIMPL 
NIMPS 


Order has completed in NetCap 


To 


UCOMP 






To 


UCOMP 
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WHAT IS CLAIMED IS: 



1 1. An interactive Web/Internet based 

2 network management system for enabling configuration of 

3 a customer's telecommunications network via an 

4 integrated interface, said system comprising: 

5 a client browser application located at a 

6 client workstation for enabling interactive Web based 

7 communications with said network management system, 

8 > said client workstation identified with a' customer and 

9 providing said integrated interface; 

10 at least one secure server for managing 

11 client sessions over the Internet, said secure server 

12 supporting a secure connection enabling encrypted 

13 communication between said client browser application 

14 and said secure server; 

15 a network configuration system for maintaining an 

16 inventory of a customer's telecommunications network 

17 call routing plans and associated plan details, and 

18 interfacing with network control elements for 

19 configuring a customer's telecommunications network 

20 according to a desired call routing plan; and, 

21 a network manager in communication with said 

22 secure server for receiving customer directives 

23 communicated over said secure connection, said 

24 directives including a request to access call routing 

25 plan details according to a selected plan, and 

26 downloading said call routing plans details to 

27 customers over said secure communications link for 

28 visual presentation at said client workstation. 
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1 2. The interactive Web/Internet based 

2 network management system as claimed in Claim 1, 

3 wherein said client browser application enables 

4 customer modification of said call -routing plan details 

5 via said integrated interface and up -loading plan 

6 detail modification directives to said network manager 

7 over said secure connection, said network manager 

8 translating said received modification directives into 

9 commands for input to said network configuration system 

10 and forwarding said commands to said network 

11 configuration system. 

1 3. The interactive Web/Internet based 

2 network management system as claimed in Claim 2, 

3 wherein said customer request messages include unique 

4 customer identifiers enabling downloading of specific 

5 call routing plan details. 

1 4. The interactive Web/Internet based 

2 network management system as claimed in Claim 3, 

3 wherein said call routing plans pertain to a customer's 

4 toll-free call network, said unique customer identifier 

5 including a specific toll-free number having one or 

6 more call routing plans associated therewith. 

1 5. The interactive Web/Internet based 

2 network management system as claimed in Claim 3, 

3 wherein said call routing plans pertain to a customer's 

4 toll-free call network, said unique customer identifier 

5 including a corporate identifier having one or more 

6 call routing plans associated therewith. 
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1 6. The interactive Web/Internet based 

2 network management system as claimed in Claim 2, 

3 wherein said customer directive includes an order to 

4 temporarily modify an existing network call routing 

5 plan for a predetermined period of time. 

1 7. The interactive Web/Internet based 

2 network management system as claimed in Claim 6, 

3 wherein said customer directive enables said call 

4 routing plan to automatically revert to a corresponding 

5 call routing plan configured prior to invocation of 

6 said directive, said directive including a revert date 

7 and time. 

1 8. The interactive Web/Internet based 

2 network management system as claimed in Claim 2, 

3 wherein said customer directive includes an order to 

4 temporarily modify a percent allocation of call traffic 

5 routed to a number used in a particular routing plan. 

1 9. The interactive Web/Internet based 

2 network management system as claimed in Claim 8, 

3 wherein said customer directive enables said allocation 

4 of call traffic routed to a number to automatically 

5 revert to a corresponding percent allocation prior to 

6 invocation of said directive, said directive including 

7 a reverting date and time. 

1 10. The interactive Web/Internet based 

2 network management system as claimed in Claim 8, 

3 wherein said directives are communicated from said 

4 integrated interface over said secure connection to 
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said network manager by a remote method invocation- like 
protocol . 

11. The interactive Web/Internet based 
network management system as claimed in Claim 4, 
wherein modifiable call routing plan detail-s include 
one selected from the group of: origin, country, state, 
day of week, time of day and termination, and any 
combination thereof . 

12. The interactive Web/Internet based 
network management system as claimed in Claim 2, 
wherein said client browser application includes 
process for enabling construction of a new routing plan 
associated with a telephone number. 

13. The interactive Web/Internet based 
network management system as claimed in Claim 2, 
wherein said network manager further comprises process 
for verifying customer entitlements prior to 
downloading call routing plans details to said 
requesting customer. 

14. A Web/Internet based network management 
system for enabling configuration of a customer's 
telecommunications network via an integrated interface, 
said system comprising: 

a client browser application located at a 
client workstation for enabling interactive Web based 
communications with said network management system, 
said client workstation identified with a customer and 
providing said integrated interface; 
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10 at least one secure server for managing 

11 client sessions over the Internet, said secure server 

12 supporting a secure connection enabling encrypted 

13 communication between said browser application client 

14 and said secure server; 

15 ' network manager for receiving customer 

16 directives communicated over said secure communications 

17 " link, said directives including a request to access 

18 call routing plan information relating to a customer's 

19 network, said network manager downloading said call 

20 routing plan information to customers over said secure 

21 connection; 

22 said client browser application enabling 

23 customer modification of said call -routing plan 

24 information via said integrated interface and up- 

25 loading call routing plan modification directives to 

26 said network manager over said secure connection; 

27 whereby said customer's telecommunications 

28 network is thereafter configured according to said 

29 commands and modified call -routing plan details 

30 included therein. 

1 15. The interactive Web/Internet based 

2 network management system as claimed in Claim 14, 

3 wherein said customer request messages include unique 

4 customer identifiers enabling downloading of specific 

5 call routing plan information. 

1 16. The interactive Web/Internet based 

2 network management system as claimed in Claim 15, 

3 wherein said call routing plans pertain to a customer's 

4 toll-free call network, said unique customer identifier 
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5 including a specific toll-free number having one or 

6 more call routing plans associated therewith. 

1 17. The interactive Web/Internet based 

2 network management system as claimed in Claim 15, 

3 wherein said call routing plans pertain to ~a customer's 

4 toll-free call network, said unique customer identifier 

5 including a corporate identifier having one or more 

6 call routing plans associated therewith. 

* 

1 18. The interactive Web/Internet based 

2 network management system as claimed in Claim 14, 

3 wherein said customer directive includes an order to 

4 temporarily modify an existing network call routing 

5 plan for a predetermined period of time. 

1 19. The interactive Web/Internet based 

2 network management system as claimed in Claim 18, 

3 wherein said customer directive enables said call 

4 routing plan to automatically revert to a corresponding 

5 call routing plan configured prior to invocation of 

6 - said directive, said directive including a revert date 

7 and time. 

1 20. The interactive Web/Internet based 

2 network management system as claimed in Claim 15, 

3 wherein said customer directive includes an order to 

4 temporarily modify a percent allocation of call traffic 

5 routed to a number used in a particular routing plan. 

1 21. The interactive Web/Internet based 

2 network management system as claimed in Claim 20, 
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3 wherein said customer directive enables said allocation 

4 of call traffic routed to a number to automatically 

5 revert to a corresponding percent allocation prior to 

6 invocation of said directive, said directive including 

7 a reverting date and time. 

1 22. A method for remotely configuring a 

2 customer's telecommunications network via a 

3 Web/Internet based integrated interface, said 

4 k integrated interface including a client browser 

5 application located at a client workstation for 

6 enabling interactive Web based communications between 

7 said customer and said integrated interface, said 

8 method comprising: 

9 managing a client session over the 

10 Web/Internet by providing a first server device capable 

11 of supporting a first secure connection enabling 

12 encrypted communication between said browser 

13 application and said first server device; 

14 providing a second server device for 

15 communicating with said first server device through a 

16 firewall over a second connection, said first secure 

17 and second connections forming a secure communications 

18 link; 

19 maintaining an inventory of a customer's 

20 telecommunications network call routing plans and 

21 associated plan details, and providing a system for 

22 interfacing with network control elements capable of 

23 configuring a telecommunications network according to a 

24 customer's network call routing plan; 

25 communicating customer request messages for 

26 accessing network call routing plans and associated 
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27 plan details over said secure communications link, said 

28 requests being associated with a customer identifier 

29 for enabling access to call routing plans and 

30 associated plan details from said inventory; 

31 downloading said call routing plan and call 

32 routing plan details as response messages feo customers 

33 over said secure communications link for visual 

■ 

34 presentation at said client workstation. 

1 23. The method as claimed in Claim 22, 

2 further including the step of enabling customer 

3 modification of said call -routing plan details via said 

4 integrated interface and up- loading plan modification 

5 directives over said secure communications link to a 

6 telecommunications network manager for receiving said 

7 directives, and translating said plan modification 

8 directives into a format capable of configuring said - 

9 customer's telecommunications network, said modified 

10 call -routing plan details being forwarded to said 

11 interfacing system for configuring said customer's 

12 telecommunications network according to said modified 

13 call -routing plan details. 

1 24. The method as claimed in Claim 23, 

2 wherein said customer request messages include unique 

3 customer identifiers enabling downloading of specific 

4 call routing plan details. 

1 25. The method as claimed in Claim 23, 

2 wherein said call routing plans. pertain to a customer's 

3 toll-free call network, said unique customer identifier 
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4 including a specific toll-free number having one or 

5 more call routing plans associated therewith, 

1 26. The method as claimed in Claim 25 , 

2 wherein said call routing plans pertain to a customer's 

3 toll-free call network, said unique customer identifier 

4 including a corporate identifier having one or more 

5 call routing plans associated therewith. 

1 27. The method as claimed in Claim 23, 

2 wherein said customer directive includes an order to 

3 temporarily modify an existing network call routing 

4 plan for a predetermined period of time. 

1 28. The method as claimed in Claim 27, 

2 wherein said customer directive enables said call 

3 routing plan to automatically revert to a corresponding 

4 call routing plan configured prior to invocation of 

5 said directive, said directive including a revert date 

6 and time. 

1 29. The method as claimed in Claim 24, . 

2 wherein said customer directive includes an order to 

3 temporarily modify a percent allocation of call traffic 

4 routed to a number used in a particular routing plan. 

1 30. The method as claimed in Claim 29, 

2 wherein said customer directive enables said allocation 

3 of call traffic routed to a number to automatically 

4 revert to a corresponding percent allocation prior to 

5 invocation of said directive, said directive including 

6 a reverting date and time. 
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1 31. The method as claimed in Claim 30, 

2 wherein modifiable call routing plan details include 

3 one selected from the group of: origin, country, state, 

4 day of week, time of day and termination, and any 

5 combination thereof. 

1 32. The method as claimed in Claim 25, 

2 further including constructing a new toll free routing 

3 i plan associated with a new toll free telephone number. 

1 33. The method as claimed in Claim 22, 

2 wherein prior to said step of downloading said call 

3 routing plan and call routing plan details as response 

4 messages to customers, the step of verifying customer 

5 entitlements for accessing said call routing plans 

6 details . 

1 34. A method for remotely configuring a 

2 customer's telecommunications network via a 

3 Web/Internet based integrated interface, said 

4 integrated interface including a client browser 

5 application located at a client workstation for 

6 enabling interactive Web based communications between 

7 said customer and said integrated interface, said 

8 method comprising: 

9 managing a client session over the 

10 Web/Internet by providing a first server device capable 

11 of supporting a first secure socket connection enabling 

12 encrypted communication between said browser 

13 application and said first server device; 
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14 providing a second server device for 

15 communicating with said first server device through a 

16 firewall over a second socket connection, said first 

17 secure and second sockets forming a secure 

18 communications link; 

19 receiving customer directives communicated 

20 over said secure communications link, said directives 

21 including a request to access call routing plan 

22 information relating to a customer's network; 

23 . downloading said call routing plan 

24 information to customers over said secure 

25 communications link; and 

26 modifying said call -routing plan information 

27 via said integrated interface and up -loading call 

28 routing plan modification directives to a network 

29 manager over said secure communications link, whereby 

30 said customer's telecommunications network is 

31 thereafter configured according to said commands and 

32 modified call -routing plan details included therein. 
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